Why sustainable software needs better defaults?
This blog is written based on my PhD research, and article titled “From Individual Responsibility to Structural Defaults: Why Does Sustainability Struggle to Scale in Software Engineering”.
Sustainability in software is often treated as a personal responsibility. A developer might care about energy use, efficient code, cloud resources, or long-term maintainability. But in everyday work, these concerns are rarely built into the structures that guide software teams.
That is why sustainability often fails to scale.
Where is the problem?
The problem is not that people do not care. In fact, many developers, managers, and organizations agree that sustainability matters. The problem is that sustainability is often positioned as something extra. Something to remember. Something to bring up if there is time. Something that depends on personal motivation.
But organizations do not run on motivation alone. They run on structures.
Every organization has guidelines, rules, routines, tools, processes, templates, dashboards, and priorities. Some of these are visible, like official development guidelines or mandatory security checks. Others are hidden, like what gets rewarded, what gets ignored, or what people know they can skip when deadlines are tight.
Together, these structures create organizational default behavior.
In software development, default behavior is shaped by things like CI/CD pipelines, code review practices, architecture templates, cloud cost alerts, security scans, performance requirements, and delivery schedules. These structures quietly tell people what matters.
If security checks are mandatory, security becomes part of normal work.
If cloud cost alerts are visible, cost becomes part of normal work.
If performance is reviewed before release, performance becomes part of normal work.
If sustainability is not included in these structures, it stays optional
This is the gap my research focuses on. Sustainability is often visible at the strategy level, but missing from the development level. It may appear in sustainability reports, company values, or public commitments, but not in the everyday tools and rules that shape how software is actually built.
That means sustainability depends on voluntary effort.
And voluntary effort is fragile.
One team might have a sustainability-minded developer who asks good questions. Another team might not. One project might consider cloud resource use. Another might focus only on speed and budget. One organization might have sustainability ambassadors, but their work may remain separate from the actual development process.
This creates uneven results. Sustainability becomes something some people do, rather than something the organization does by default.
To change this, organizations first need to recognize their existing default behavior. What are people already guided to do? What do the current structures reward? What do the guidelines make mandatory? What do dashboards make visible? What do review processes ask teams to justify? What gets dropped when time is limited?
Before changing behavior, you need to understand the guardrails that already produce it
After that, the organization can start adjusting the rules of the game.
For sustainable software, this could mean adding sustainability questions to architecture reviews. It could mean monitoring cloud resource use alongside cost and performance. It could mean creating development guidelines that ask teams to justify major increases in computation, storage, or data transfer. It could mean choosing more efficient defaults in tools, libraries, and infrastructure when they meet the same functional needs.
The point is not to make developers carry more responsibility alone. The point is to design the organization so that the desired behavior becomes easier, more visible, and more natural.
If the target behavior is sustainable software development, then the structures need to support that behavior.
Sustainability should not depend on exceptional people making exceptional effort. It should be part of how the organization normally works.
That is the real shift: from individual responsibility to organizational defaults.
